[セッションレポート]AWS under the hood 〜AWSを中で支えるサービス群について語る〜 #jawsdays2022 #jawsdays #jawsug

あしざわ

2022.10.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさん、こんにちは。

AWS事業本部コンサルティング部@東京オフィスの芦沢(＠ashi_ssan)です。

今回は2022年10月8日に開催されたJAWS-DAYS 2022 - Satellitesのセッションレポートを行います。

AWS under the hood 〜AWSを中で支えるサービス群について語る〜

セッション概要

概要

クラウドコンピューティングは、 2006年3月に誕生しお客様のフィードバックをもとに成長してきました。このセッションではクラウドコンピューティングの中でもエンジニアの皆さんに大人気のサーバレスコンピューティング基盤を例により、 AWSの哲学に基づきどのように基盤が進化してきたか？をご紹介させていただきます。また昨今のDiversityが重視される世の中において、クラウドコンピューティングと多様化の親和性や、細分化し続けるユーザーの購買行動との付き合い方などについてご紹介します。

登壇者

亀田治伸さん

AWSJ エバンジェリスト5号機。実は一番長持ち

動画

レポート

導入

AWSの中身の話をしながら、Amazonカルチャーを伝えるセッション！
Diversity
- 企業が女性の社会進出を積極的に支援する
  - これは合ってる？違う？
- 本来はもっと生々しい話
  - より良い労働環境を整備して、皆に楽しく働いてもらう
  - 綺麗事ではなく、企業の生存戦略
Amazonが考えるDiversity
- 世界中のすべての人に物を売りたい = 世界中のすべての人を理解したい
- AmazonにとってDiversityは当たり前の考え方
  - とはいえ世界中に人間に合わせるのは難しいため、カテゴライズする（男性、独身など）
データ爆発（Data Explosion）が発生し、徐々にカテゴライズが困難になっている
- SNSによって人格を使い分けることができるようになった
  - 企業は1人の人間を複数の人格として分割して管理できる
- ユーザーの思考が細分化
  - 企業がビジネスのターゲット層が正しいか？を再定義する必要がある
  - 適切なユーザーに適切なメッセージを送ることが必要とされている
例）ECサイトのヘッドレスコマース
- マイクロサービスがどのように役に立つのか？は議論されているが、全ての物事を解決するわけではない
- 例えばDBのセキュリティを中心に考える
  - ECサイトのDBは個人情報の塊（名前、メールアドレス、クレカ情報）
  - このような例でチーム毎にDBを持つことが許容できるか？場合によっては無理
- このような議論から生まれたさまざまな考え方
  - 分散モノリス
    - 重要なDBは1つだけ、配下にチーム毎のマテリアルビュー
  - モジュラーモノリス
    - アプリの開発はチーム毎に自由、最終的な連結は統一しデプロイは一括
- エンジニアチームのあり方も変わった
  - 従来のIT企業の枠組みでは対応できない
    - 従来）テクノロジースタックごとに1つのチームに固める
      - ネットワーク、DBの勉強にお金がかかっていた
    - クラウド）多様性を持ったメンバーを1つのチームに固める
      - ネットワークやDBなどの学習コストが下がったことで可能に
    - You Build, You Run it.
      - 「開発した人がそのまま運用する」という当たり前の考え方
  - 今日までにAWSは多くのコンピュート環境を抽象化し使いやすくした

AWSはLambdaをどう改善していったか？

2014年にリリース
イベント駆動アーキテクチャ
Lambdaのライフサイクル
- イベント駆動でマイクロVMが起動し、アプリケーションが実行される
- アプリの実行後はマイクロVMは廃棄される
- →コンピュートリソースが無駄にならない
リリース当初はLambdaの重要性に気づいている人は少なかった（AWS内部でも外部でも
発表当初の対応サービス
- S3,Kinesis,DynamoDB
制約も多かった
- 最大1GBメモリ,256スレッド,最大実行時間25,同時実行数25
- API Gateway,EventBridge非対応
- VPCアクセスなし
- 抱えていた課題 = コールドスタートが重い
  - 実行後のマイクロVMが残っている”しばらくの間”は処理が早いが、廃棄された後は数百msec単位の待ち時間が発生
その後改善された！
初期のLambda
- 起動後、裏側で専用EC2インスタンスが作成されていた（AWSは顧客に費用は請求しない）
- 裏側に問題があったとしたらAWSは改善していく
改善のためにリリースされたもの
- Nitro System
  - ハードウェアベースのHypervisorで高いセキュリティを確保
  - ゲストOSが外と通信する場合にホストOSのリソースを使用する
- Firecracker
  - Fargateでも使用されているFramework
  - 単一なハードウェアの上で大量のMicro VMを高速に安全に起動する
1つのベアメタルインスタンスの上に複数AWSアカウントの環境を起動できるようになった
- 結果として、コールドスタートの問題が改善した
もう1つ改善したもの = VPC / Databaseアクセス
- RDBは常にVPCの中にある
  - 外からアクセスするためには？
- そもそもLambdaの実態はどこにあるのか？
  - リージョンの何処か → Yes
  - AZの何処か → Yes and No, しかし単一のAZではない
  - 正解は、Lambdaは自前のVPC（サービスVPC）を持っている
  - コールドスタートの場合、動的にENIを作成していたために数十秒かかっていた（最大50秒くらい）
VPCシェアリング
- VPC共有を実装している内部構造 = Hyperplane
- Hyperplaneによってネットワークオブジェクトを”もう一度”仮想化させた
  - EC2は仮想化されているがハードウェアの上にある、そのため1つのAZに紐ついている
- LambdaのVPCアクセス環境を作成したタイミングでHyperplaneが仮想化されたENIを作成する
  - 昔はLambda関数が起動するタイミングでENIが動的に作成されていた
- HyperplaneがENIを作成（数週間くらいのKeepAlive）、コールドスタートが起きにくくなった
V2N（VPC to VPC NAT）
- Hyperplaneで仮想化されたENIを動的にユーザーのVPC内のENIに関連付けする
- セキュリティグループはHyperplane側のENIにあるため、高速なVPCアクセスを実現
Lambdaの起動タイプ
- 同期型：API Gatewayから呼ばれた時
  - フロントエンドがVMへ通信をルーティング
- 非同期型：S3へのObjectのPut
  - フロントエンドが通信を内部キューにルーティングし、VMへ到達
- イベントソースマッピング型：Kinesis
  - フロントエンドの前段にイベントソースマッピングが配置
AWSでのコンピューティングは多くの選択肢が増えたために、学習難易度は上がっている
今年のre:Invent2022でも「何か」が出る！？！？！？